NOTE

1.30 InnoDB MVCC

1. What Is MVCC - Multi-Version Concurrency Control - To allow read-write operations from different transactions to execute concurrently, data is maintained in multiple versions, and transaction visibility determines which data version a transaction should see 2. MVCC Principle - Where to get data from: version chain - Which version of the data to get: ReadView 2.1. Version Chain - InnoDB undo log.md

DatabasesCreated Updated 2 min readhistorical

This is a historical learning note and may contain outdated or incomplete understanding.

1. What Is MVCC

  • Multi-Version Concurrency Control.
  • To allow read-write operations from different transactions to execute concurrently, data is maintained in multiple versions, and transaction visibility determines which data version the transaction should see.

2. MVCC Principle

  • Where to get data from: version chain.
  • Which version of the data to get: ReadView.
2.1. Version Chain
  • InnoDB undo log.md
  • Each record has two hidden fields: trx_id and roll_pointer.
    • trx_id: the transaction ID of the transaction that modified the record.
    • roll_pointer: after a record is modified, the old record is placed in the undo log, and roll_pointer points to the old record.
  • Multiple undo logs for the same record are linked together into a linked list. This is the version chain.
2.2. ReadView
2.2.1. Purpose of ReadView
  • Determine which version in the version chain is visible to the current transaction.
2.2.2. What Is ReadView
  • m_ids: the list of active transaction IDs in the system when the ReadView is generated.
  • min_trx_id: the minimum value in m_ids.
  • max_trx_id: the ID value that should be assigned to the next transaction in the system when the ReadView is generated.
  • creator_trx_id: the transaction ID of the transaction that generated the ReadView.
2.2.3. ReadView Decision Process
  • The accessed version’s trx_id = creator_trx_id in the ReadView: the current transaction is accessing a record it modified itself, so this version can be accessed by the current transaction.
  • The accessed version’s trx_id < min_trx_id in the ReadView: the transaction that generated this version committed before the current transaction generated the ReadView, so this version can be accessed by the current transaction.
  • The accessed version’s trx_id >= max_trx_id in the ReadView: the transaction that generated this version started only after the current transaction generated the ReadView, so this version cannot be accessed by the current transaction.
  • min_trx_id in the ReadView <= the accessed version’s trx_id < max_trx_id in the ReadView:
    • if trx_id is in the m_ids list, the transaction that generated this version was still active when the ReadView was created, so this version cannot be accessed;
    • if trx_id is not in the m_ids list, the transaction that generated this version had already committed when the ReadView was created, so this version can be accessed.

Discussion

Sign in with GitHub to comment. Discussions are stored as GitHub Issues.View on GitHub